Guidance engine: an automated system and method for providing financial guidance

ABSTRACT

Aspects described herein may allow for receiving, by a detection server, a plurality of configuration parameters, wherein each configuration parameter includes a type of a risk and an associated level of the risk, with a corresponding automated remediation action for each configuration parameter. A remediation management framework authenticates the detection server for access to the remediation management framework and initiates a scanning of a system of interest, based on the plurality of configuration parameters, by the detection server, to identify one or more risk findings. The remediation management framework receives the identified one more risk findings; and matches each of the one or more risk findings with the plurality of configuration parameters, which then triggers by the remediation management framework, the corresponding automated remediation action associated with each of the one or more risk findings.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of and claims priority toco-pending U.S. patent application Ser. No. 17/322,968 filed on May 18,2021, entitled “Guidance Engine: An Automated System and Method forProviding Financial Guidance,” which is a continuation of and claimspriority to U.S. patent application Ser. No. 16/680,793 filed on Nov.12, 2019 entitled “Guidance Engine: An Automated System and Method forProviding Financial Guidance” and issued as U.S. Pat. No. 11,023,967 onJun. 1, 2021, the disclosure of which is hereby incorporated byreference in its entirety.

FIELD OF USE

Aspects of the disclosure provide for systems and methods to the fieldof automated risk assessment guidance software. More particularly,aspects of the disclosure are directed to automated financial analysissoftware systems.

BACKGROUND

The majority of Americans are burdened with high-interest rate debt andhave less than $1,000 is savings. Approximately 69% of Americans haveless than $1,000 in savings and 34% have no savings at all. The averagehousehold in the United States owes $6,829, based on 2016 data, inrevolving credit card debt and pays an average of $1,141 in annualinterest on that credit card debt. And, 78% of American are somewhat orextremely concerned about not having enough money for retirement.

Some of the above individuals have debt levels under 3,500 per personand under the proper identification and guidance could remove themajority of their debt in under six months. For those financiallyvulnerable individuals that have less than one month of savings fortheir committed monthly expenditures, they could save one month ofcommitted monthly expenditure if they were to save 10% of theirdiscretionary income per month for one year. However, while some ofthese individuals can improve their own financial health, manyindividuals do not have the knowledge or expertise to know what to doand how to do it.

BRIEF SUMMARY

Given the foregoing, many of the above identified individuals wouldbenefit from unbiased, personalized, financial advice, but either can'tafford or don't trust traditional financial advisors. While there arenumerous on-line financial resources, there is no easy or accurate wayto ascertain what is a correct approach for each individual. Therefore,what is needed is a system and method for digital guidance and advicebased on a Guidance Engine that provides individuals with both holisticfinancial guidance and the resources to stay on track as they improvetheir financial health. Such an approach is based on a backend serversystem that analyzes a user's financial accounts and provides concrete,personalized steps to becoming more financially healthy based on aframework and methodology outlined below.

The following presents a simplified summary of various aspects describedherein. This summary is not an extensive overview, and is not intendedto identify key or critical elements or to delineate the scope of theclaims. The following summary merely presents some concepts in asimplified form as an introductory prelude to the more detaileddescription provided below.

Aspects discussed herein may provide a computer-based automated systemfor providing financial guidance. According to at least one aspect, acomputer based automated system for providing financial guidanceincludes a guidance engine application program interface configured forend-user access in which a guidance engine includes an input system anda decision tree system. The input system is designed to receive inputdata based on a user's financial status and may include an initialcalculation to optimize and integrate the input data based on at leastan availability of data and generate an output set comprising estimatedcommitted monthly expenses, income, emergency fund level and a highinterest debt level of the user. The decision tree system is designed toaccept the output set and an associated confidence score for eachcomponent of the output set, where the decision tree system may performan intermediate calculation based on the user's emergency fund level andhigh interest debt level, and then ranks the user based on the initialcalculation and the intermediate calculation using a financial bestpractices standard to determine a suggested next financial action step.

In another embodiment, a computer-implemented method for providingfinancial guidance includes gathering input data on a user includingdata corresponding to a user's monthly expenses, income, emergency fundlevel, and high interest debt level. The method may then perform aninitial calculation on the input data to estimate committed monthlyexpenses of the user and an estimated monthly income of the user,wherein committed monthly expenses are defined as a total monthly fixedexpense incurred by the user to cover essential needs and the estimatedmonthly income includes a gross, a net and a discretionary income. Themethod continues by performing an intermediate calculation to generatean estimated emergency fund level of the user and an estimated highinterest debt level of the user, wherein the estimated emergency fundlevel is based on an amount of liquid assets available to cover theuser's estimated committed monthly expenses, and wherein the estimatedhigh interest debt level may include a loan with an interest rate abovea pre-set threshold. The method then generates, based on the input data,a confidence score comprising a variability score and a reasonablenessscore for each of the user's estimated committed monthly expenses,estimated monthly income, estimated emergency fund level, and estimatedhigh interest debt level. The method then categorizes the financialsituation of the user, based on the user's estimated emergency fundlevel and estimated high interest debt level, using a financial bestpractices standard to determine a suggested next financial action step.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 depicts an example of a computing device that may be used inimplementing one or more aspects of the disclosure in accordance withone or more illustrative aspects discussed herein;

FIG. 2 depicts an overview block diagram of a guidance engine with itsthree main components in accordance with one or more illustrativeaspects discussed herein;

FIG. 3 depicts an overview flow diagram of the structure of the guidanceengine application program interface with one or more illustrativeaspects discussed herein;

FIG. 4 depicts a flow diagram of a guidance engine method in accordancewith one or more illustrative aspects discussed herein.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings, which form a part hereof, and inwhich is shown by way of illustration various embodiments in whichaspects of the disclosure may be practiced. It is to be understood thatother embodiments may be utilized and structural and functionalmodifications may be made without departing from the scope of thepresent disclosure. Aspects of the disclosure are capable of otherembodiments and of being practiced or being carried out in various ways.Also, it is to be understood that the phraseology and terminology usedherein are for the purpose of description and should not be regarded aslimiting. Rather, the phrases and terms used herein are to be giventheir broadest interpretation and meaning. The use of “including” and“comprising” and variations thereof is meant to encompass the itemslisted thereafter and equivalents thereof as well as additional itemsand equivalents thereof.

By way of introduction, aspects discussed herein may relate to systems,methods, techniques, apparatuses, and non-transitory computer readablemedia findings remediation management framework system. For example, asoftware system of interest may contain one or more compliance issues,or an area of software that is not in compliance in terms of systemsecurity or functionality, which once detected, needs to be remediated.Such remediation can take many forms such as an email notification,shutting down a server, or further data analysis.

Before discussing these concepts in greater detail, however, severalexamples of a computing device that may be used in implementing and/orotherwise providing various aspects of the disclosure will first bediscussed with respect to FIG. 1 .

FIG. 1 illustrates one example of a computing device 101 that may beused to implement one or more illustrative aspects discussed herein. Forexample, computing device 101 may, in some embodiments, implement one ormore aspects of the disclosure by reading and/or executing instructionsand performing one or more actions based on the instructions. In someembodiments, computing device 101 may represent, be incorporated in,and/or include various devices such as a desktop computer, a computerserver, a mobile device (e.g., a laptop computer, a tablet computer, asmart phone, any other types of mobile computing devices, and the like),and/or any other type of data processing device.

Computing device 101 may, in some embodiments, operate in a standaloneenvironment. In others, computing device 101 may operate in a networkedenvironment. As shown in FIG. 1 , various network nodes 101, 105, 107,and 109 may be interconnected via a network 103, such as the Internet.Other networks may also or alternatively be used, including privateintranets, corporate networks, LANs, wireless networks, personalnetworks (PAN), and the like. Network 103 is for illustration purposesand may be replaced with fewer or additional computer networks. A localarea network (LAN) may have one or more of any known LAN topologies andmay use one or more of a variety of different protocols, such asEthernet. Devices 101, 105, 107, 109 and other devices (not shown) maybe connected to one or more of the networks via twisted pair wires,coaxial cable, fiber optics, radio waves or other communication media.

As seen in FIG. 1 , computing device 101 may include a processor 111,RAM 113, ROM 115, network interface 117, input/output interfaces 119(e.g., keyboard, mouse, display, printer, etc.), and memory 121.Processor 111 may include one or more computer processing units (CPUs),graphical processing units (GPUs), and/or other processing units such asa processor adapted to perform computations associated with databasequeries, interactions with client applications, scheduling and trackingof scan requests associated with a system of interest, generatingremediation actions associated with a completed scan, logging scanresults, logging remediation actions and risk levels in a database, andother functions. I/O 119 may include a variety of interface units anddrives for reading, writing, displaying, and/or printing data or files.I/O 119 may be coupled with a display such as display 120. Memory 121may store software for configuring computing device 101 into a specialpurpose computing device in order to perform one or more of the variousfunctions discussed herein. Memory 121 may store operating systemsoftware 123 for controlling overall operation of computing device 101,control logic 125 for instructing computing device 101 to performaspects discussed herein. Furthermore, memory 121 may store variousdatabases and applications depending on the particular use, for example,customer database 127, bank database 129, third-party provider database131, and other applications 133 may be stored in a memory of a computingdevice used at a server system that will be described further below.Control logic 125 may be incorporated in and/or may comprise a linkingengine that updates, receives, and/or associates various informationstored in the memory 121 (e.g., authentication information, riskmanagement information, and remediation information, etc.). In otherembodiments, computing device 101 may include two or more of any and/orall of these components (e.g., two or more processors, two or morememories, etc.) and/or other components and/or subsystems notillustrated here.

Devices 105, 107, 109 may have similar or different architecture asdescribed with respect to computing device 101. Those of skill in theart will appreciate that the functionality of computing device 101 (ordevice 105, 107, 109) as described herein may be spread across multipledata processing devices, for example, to distribute processing loadacross multiple computers, to segregate transactions based on geographiclocation, user access level, quality of service (QoS), etc. For example,devices 101, 105, 107, 109, and others may operate in concert to provideparallel computing features in support of the operation of control logic125 and/or customer database 127.

One or more aspects discussed herein may be embodied in computer-usableor readable data and/or computer-executable instructions, such as in oneor more program modules, executed by one or more computers or otherdevices as described herein. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data typeswhen executed by a processor in a computer or other device. The modulesmay be written in a source code programming language that issubsequently compiled for execution, or may be written in a scriptinglanguage such as (but not limited to) HTML or XML. The computerexecutable instructions may be stored on a computer readable medium suchas a hard disk, optical disk, removable storage media, solid statememory, RAM, etc. As will be appreciated by one of skill in the art, thefunctionality of the program modules may be combined or distributed asdesired in various embodiments. In addition, the functionality may beembodied in whole or in part in firmware or hardware equivalents such asintegrated circuits, field programmable gate arrays (FPGA), and thelike. Particular data structures may be used to more effectivelyimplement one or more aspects discussed herein, and such data structuresare contemplated within the scope of computer executable instructionsand computer-usable data described herein. Various aspects discussedherein may be embodied as a method, a computing device, a dataprocessing system, or a computer program product.

Having discussed several examples of computing devices which may be usedto implement some aspects as discussed further below, discussion willnow turn to an illustrative environment and network for a guidanceengine framework and methodology.

In an embodiment, the guidance engine framework consists of multiplecomponents working together to translate a customer's data into concretefinancial advice. An “inputs” component optimizes a customer's data andmay perform a series of calculations related to Emergency Funds (EF) andHigh Interest Debt (HID). A “decision tree” component uses thecalculated values from the inputs component to identify the appropriatefinancial recommendation for the customer. The decision tree componentfollows a financial playbook referred to as the “Financial BestPractices” (FBP) Standard, which will be discussed in further detail.

To determine a customer's accurate financial guidance, that customer'sfinances need to be reviewed. At the most basic level, such a review mayinclude identifying the customer's spending patterns, liquid assets andhigh interest debt levels. To understand customer spending,transactional data can be mined from a financial institution, inaddition to data from credit bureaus, e.g., Equifax, Experian, andTransUnion. The guidance engine may also utilize cost-of-living (COL)data from publicly available sources, such as the MassachusettsInstitute of Technology Living Wage Project and the American CommunitySurvey (ACS). In addition to providing a benchmark value for thedifferent categories, this external data may provide some roughestimates for customer spending based on their geographic location.Thus, even when a customer does not utilize a financial institution'saccount, a rough estimate of their categorized spending can still bedetermined.

As part of an analysis of the customer's financial picture, eachcustomer's liquid assets may also be analyzed. Liquid assets are definedas money a customer has available to spend in case of an emergency.Liquid assets, for this application, may include the sum total of acustomer's savings, checking, and money market balances and any othersources of readily accessible monies. If a financial institution cannotdetermine a customer's liquid assets, then a third-party provider, e.g.,IXI data, may be used to provide a rough estimate of the customer'sassets, savings, and investments, as benchmark values, and as a proxywhen customer data is unavailable. Similar to the use of COL datadescribed above, third-party provider data may provide estimates of acustomer's net worth and assets based on their geographic location.Customers also have an opportunity to inform their financial institutionabout assets external to their financial institution and whether or notfunds are earmarked for emergencies.

To estimate the amount of High Interest Debt each customer is carrying,such data may be extracted from a financial institution. This mayinvolve looking at both a customer's card accounts and using creditreport information to identify debt external to a financial institution.

FIG. 2 depicts an overview block diagram of a guidance engine system 200with its three main components in accordance with one or moreillustrative aspects discussed herein. Guidance engine system 200includes features system 210, guidance engine 220, and outputs system230. Further, guidance engine 220 includes an inputs section 222 and adecision tree system 224.

In an embodiment, inputs section 222 accepts internal and external datafrom a financial institution's internal data systems or externalthird-party systems to analyze a user's finances. Inputs section 222includes two sets of calculations including an “initial” and“intermediate” calculations as will be discussed in further detail.Further, each subcomponent of code within inputs section 222 may bemaintained as its own individual script that can utilize commonfunctions that allows for modification at the subcomponent level.

For each user, or “customer,” of a financial institution, guidanceengine 220 accepts multiple data points, in some embodiments there areover 80 different data points, that can include data from within afinancial institution, e.g., when a customer tells the financialinstitution specific financial values such as their amount of committedmonthly expenses (“CME”). Committed monthly expenses is defined as theamount of fixed costs a customer must pay at a minimum each month.Guidance engine 220 then utilizes this data, where for the initialcalculations, the guidance engine may optimize and integrate the dataused for a given customer based on availability, ensuring that theguidance engine utilizes the best data available for each customer.

For the intermediate calculation, guidance engine 220 may perform aseries of calculations related to emergency funds and high interest debtto determine values such as discretionary income and the time needed topay down a customer's debt. The output, or values determined by inputssection 222, are then used by decision tree system 224 where decisiontree system 224 places each customer in an FBP standard where the FBPstandard defines where a customer stands financially and indicates whichaspect of their personal finances should be addressed. The FBP standardillustrates a progressive customer flow, taking the customer throughsteps of building an emergency fund and paying down debt until they arefinancially stable enough to invest. Table 1 below illustrates a summaryof a possible guidance engine FBP standard.

TABLE 1 FBP Standard Emergency High Interest Debt Load Fund NoneModerate High <1 CME Customer must save a baseline level of 1 CME inliquid assets before considering other financial goals. <3 CME CustomerCustomer should allocate funds to either Emergency Fund, should saveDebt Paydown, or both. 3 CME. <6 CME Customer Customer should pay downCustomer should pay down debt should save debt with recurring payments.with lump and/or recurring 6 CME. They are also eligible to savepayments. They are also eligible for Emergency Fund. to save forEmergency Fund. >6 CME Customer is Customer should pay down Customershould pay down debt ready to debt with recurring payments with lumpand/or recurring Invest. payments

Guidance engine 220, for each customer, may return multiple data values,including optimized data values, calculated values, recommendedfinancial advice, data sourcing flags, and a series of metricquantifying a confidence level in each output.

FIG. 3 depicts an overview flow diagram of the structure of the guidanceengine application program interface 300 in accordance with one or moreillustrative aspects discussed herein. Guidance engine applicationprogram interface 300 includes four distinct structural components thatincludes a call to guidance application program interface 310, a dataintegration system 320, a guidance engine back-end 330 and guidanceengine outputs 340.

Guidance application program interface 310 may be used by customers andclients to access and make requests of the guidance engine. Inputs toguidance application program interface 310 may include a customeridentification and other inputs such as asset values, income levels,expenses, debt and any other financial data. Data integration system 320accepts the inputs from guidance application program interface 310 andthen combines implicit and explicit data, where the implicit data caninclude default guidance-related data and explicit data can include anycustomer supplied information. Guidance engine back-end 330 uses thecombined data from data integration system 320 using best practicerecommendations for a user's financial situation. Guidance engineoutputs 340 generates recommendations and requests for additionalinformation. Recommendations can include information relating to highinterest debt and emergency savings. Requests for additional informationcan include suggested areas to request user input for improvedrecommendations and can also include logging of any inputs and outputs.

Guidance Engine—Inputs

The Guidance Engine may use both internal and external data sources toexamine a customer's finances and provide a recommendation. When a usercalls guidance application program interface 310 using an applicationprogram interface (API), a customer's data is pulled from a customerdatabase, for example, customer database 127. This data can beautomatically refreshed on a periodic basis.

As mentioned above, inputs sections 222 may accept both internal datafrom a financial institution and external data, such as from athird-party provider. Internal data sources may be broken down intomultiple categories. For example, internal data can include financialinstitution data, i.e., bank data and card data, and external data,i.e., bureau data and other third-party data.

Bank Data may include transaction level data as well as checking andsavings balances. Card Data may include transaction level data, creditcard balances, annual percentage rate (APR), minimum payments, days inbilling cycle etc. Bureau Data is extracted data on a customer'sexternal data from credit bureau, for example the three Credit Bureaus:Equifax, Experian and TransUnion. This may include total revolvingbalances and monthly payments on auto loans, mortgages, external creditcards, and student loans. Note that this data can be updated on aperiodic basis for institutional customers and third party data can beused to provide a rough estimate of the customer's assets, savings,investments, etc.

The External Data Sources used by the Guidance Engine may include atleast the following resources: COL estimates from external data sourcesuch as the MIT Living Wage Estimates that may include the MIT LivingWage Calculator that combines numerous data sources to estimate the costof living across the U.S. for different types of households. Using a webscraper, data, organized by County may then be associated with eachcustomer with the appropriate County, via a 5-digit zip code. Thus, evenif a financial institution is not a customer's primary financialinstitution, a broad estimate of the customer's expenses, based on theirresidence, can be estimated. Further, the MIT Living Wage Calculatorlists the Annual Expenses for a range of different household types,including food, childcare, medical, housing, transportation, annualtaxes, etc. And, the Living Wage Calculator may also provide detailsabout minimum income required to cover these expenses for differenthouseholds.

External data can also include American Community Survey (ACS) Data,that is in contrast to the Census, which focuses on accurate populationnumbers, the ACS contains information about a population'scharacteristics, such as their job, education, home-ownership, etc. ACSdata provides higher geographic resolution across the entire country, incontrast to the MIT Living Wage data that is based on counties. Incontrast, the ACS may use the customer zip codes to associate eachindividual with their associated Block Group, which has a populationranging between 600 and 3000 people. Data points can be obtained fromACS and include rent payments, mortgage payments, and per capita grossincome.

External data can also include user augmented data that is provided by acustomer. The fundamental issue faced by the guidance engine is datasufficiency. There can be instances where the guidance engine does nothave enough information about a given customer, despite them having aprimary banking relationship with a financial institution. Thus,customers can augment any of the estimated values, in which the guidanceengine will update its outputs based on the additional information.Customer augmentations are possible for the different expensecategories, income-related values, liquid assets, and high interestdebt.

Transformations

As discussed above, multiple data points may be extracted from internaland external sources for Guidance Engine 220. While some of these can beused as-is, many may have to be transformed. Some of the critical datatransformations leveraged by the Guidance Engine are discussed below.Such transformations listed below can occur in Guidance Engine 220 or byother computational resources, such as computing device 101. Suchtransformation systems may also be referred to as a featurizationsystem, where the featurization system transforms the input data into aformat appropriate for guidance engine 220.

Guidance engine 220 may also be configured to perform unit testing toensure that all data transformation behave as expected. For example, foreach transformation, fake data can be created that test a range ofdifferent edge cases, specific to the transformation itself. Forexample, if a data system is designed for aggregating customer bankingbalances to get their total amount of funds in savings, the fake datawill include examples of customer ids with multiple associated balances,null values, etc. The testing infrastructure would run the associatedtransformation on this fake data, comparing its output to the expectedvalues, alerting as to any differences. These unit tests are thenleveraged to ensure that any new feature ready for deployment is usingappropriate transformations, logic, and calculations.

Median values of Expense Categories: A standard procedure can be usedfor transforming transaction-level data into a customer's categorizedmonthly spend. For example, a year's worth of transaction data for eachcustomer from both a financial institution and credit card providers canbe used. Each transaction is categorized via relevant Merchant CategoryCodes. Merchant category codes may be used to associate individualfinancial institution and credit card transactions with differentspending categories. These codes are defined by the card companies(e.g., Visa, Mastercard), where merchants are assigned a specific codebased on their primary line of business at the point in time when theystart accepting card payments. Note that not all transactions maycontain an associated code.

Further, for each customer, the total spend per month in each expensecategory is summed for both financial institutions and credit cardproviders. The median monthly spend may then be calculated for eachexpense category over the span of a year. The interquartile ranges mayalso be calculated for each of the expense categories, to quantifymonth-to-month variability over the previous year. For a given customerand expense category, the median monthly spend from credit cardproviders and the median monthly spend from the financial institutionsmay be summed as their monthly spend.

To determine the overall variability in an expense category, the squareroot of the sum of the squares of the variability in financialinstitution and credit card provider monthly spend may be determined.

Total Monthly Spend: To estimate a customer's total monthly spend, asimilar transformation may be used as detailed for categorized expenses.For each customer, the monthly outflow for both financial institutionsand credit card transactions may be summed. The median and interquartilerange (IQR) spend per month are then calculated, over the span of theprevious year for both financial institutions and credit card providers.The sum of the median monthly spend from financial institutions and themedian monthly spend from credit cards is a customer's total monthlyspend. To determine the overall variability, the square root of the sumof the squares is taken of the variability in financial institution andcredit card monthly spend.

Net Income: For some customers, their typical monthly credits toestimate their net income may be used. The data is transformed using asimilar methodology to Monthly Spend and Expense Categories, asdescribed below: For each customer, the sum of all credits depositedinto bank accounts on a month-by-month basis is determined. Using ayear's worth of data, the median and IQR of monthly credits as a proxyfor net income is determined.

Total Minimum Payments for Credit Cards: To determine the total creditcard minimum payments, the sum of the minimum payments of all creditcards reported in the credit bureau data may be calculated. For example,TransUnion provides information on up to 7 different revolving creditcards, sharing the balance and minimum payment. There is no informationabout the type of card, interest rate, and/or company. This informationis also not available from any of the other credit bureaus, whichaggregate across individual cards rather than sharing their individualinformation. Note that the card information provided by TransUnionincludes minimum payments made.

Total Revolving Card Debt: For a customer with a financial institution,that institution has a wealth of information, from balances, to minimumpayments, to terms and conditions. However, data on debt external to thefinancial institution is much more limited. Only TransUnion reportsCredit Card data on an individual account basis, providing minimumpayment and current balance due for up to 7 revolving credit cards.

Rather than aggregating, a summary of a customer's debt on anaccount-by-account level may be performed. Each account is a separateentry in a data dictionary and can contain financial information, forexample, the last 4 digits of the account number as an identifier;annual percentage rate (APR); revolving balance (note that for externalcredit cards, this is the current balance so is not necessarilyrevolving); minimum payment due; interest cost to pay down debt bypaying the minimum due every month; time to pay down debt by paying theminimum due every month.

Customers may also augment the data associated with their individualdebt accounts within the guidance engine. For example, a customer candisclose an APR on an external credit card account, which can then beintegrated into a debt data dictionary.

Gross Income: To estimate a customer's gross income values disclosed bythe customer themselves are utilized, whenever available. Specifically,values supplied via credit card applications or requests for creditlimit increases can also be used. However, because these values are notalways kept up to date, only values provided within the past 3 yearsshould be used. Additionally, for incomes more than one year old, theycan be scaled by 3% per year, to account for typical pay increases

Data Optimization: Once the input data has been appropriatelytransformed, the information may be optimized to be utilized by theguidance engine for a given customer. Data from both external andinternal sources may be used where, for a given customer and data point,the best data available may be used, where “best” is defined byproximity to an individual customer. Augmented information from thecustomer is the highest priority, which a customer provides directly viathe guidance engine API discussed above. Similarly, information based ona customer's transactions may take precedence over data sourcedexternally (e.g., estimates of a customer's monthly food costs based onactual transactions have a higher priority than estimated values basedon their geography).

Calculations

Once the input information has been optimized, the guidance engine mayperform a series of calculations as defined in the following categories.

-   -   Committed Monthly Expenses (CME).    -   Income: Income can be defined as Gross, Net, and Discretionary.    -   Emergency Fund: Emergency fund is classified as Emergency Fund        Shortfall, Monthly Saving Goal Amounts, and Timescale to reach        Emergency Fund Goal.    -   High Interest Debt: High interest debt is classified as Debt        Paydown Strategies, cost benefit analyses, Monthly Debt Paydown        Amounts, and Timescale to Paydown Debt,    -   Confidence Scores: Confidence scores are metrics that quantify a        level of accuracy for each guidance engine component.

Committed Monthly Expenses (CME): Committed Monthly Expenses may bedefined as the total monthly fixed expenses incurred by a customer tocover their essential needs. These can be broken down into the followingexample, but not all inclusive, expense categories:

-   -   Childcare;    -   Credit Card Minimum Payments;    -   Food;    -   Housing;    -   Insurance;    -   Medical;    -   Phone/Cable/Internet;    -   Student Loan Payments;    -   Tax;    -   Transportation; and    -   Utilities.

The general protocol for estimating the above values is as follows:

-   -   1. User-augmented data whenever available.    -   2. In the absence of user-augmented data, Merchant Category        Codes may be used. Total spend in a given category is the sum of        the median values from financial institutions and credit card        providers.    -   3. When transaction-based data is not available, Credit Bureau        data can be utilized, including Student Loan Payments, External        Credit Card Minimum Payments, Auto Loan Payments, Mortgage).    -   4. In the absence of transaction and bureau data, geographic        benchmark estimates can be utilized. For each customer with a        valid zip code, data on categorized cost-of-living from the MIT        Living Wage Project and housing costs from the American        Community Survey can be utilized. Note that value from the MIT        Living Wage Project assume a single adult with no dependents.        However, this limitation can be augmented based on each        customer's household type.    -   5. If none of the above is available, the relevant value is set        to null.

Any exceptions from the above general protocol is specified below inTable 2, table of calculations.

TABLE 2 Table of Calculations Reason- able- Confi- Aug- Variability nessdence ment Category Feature Description of Logic Benchmark Score Scorescore able? Source COSTS Home Rent 1. Median monthly costs ACS DEFAULTDEFAULT DEFAULT N 1. Rental-related based on transaction history oftransactions from last 12 months of bank and/or Financial institutionand card data. card accounts, identified 2. If no values available,value using MCC codes. set to null. Mortgage 1. If IFM mortgage data isACS STDDEV DEFAULT DEFAULT N 1. Transactions related available, then itis used. to mortgage payments 2. In the absence of 1, the from Financialmaximum value of the institution accounts monthly mortgage paymentsmined through a third- reported from Equifax, party platform calledExperian, and TransUnion is Insight Financial used. Marketing(IFM). 3.In the absence of these 2. Mortgage Payments values, the value is set tonull. from the three credit bureaus-Equifax, Experian and TransUnion.Combined 1. Augmented data is used ACS WEIGHTED DEFAULT DEFAULT Y 1.User Input whenever available. 2. Combination of Rent 2. If Rent and/orMortgage and/or Mortgage Costs costs calculated above, 3. MonthlyHousing combine these values. Costs from Customer 3. In the absence of 1and 2, Credit Card Application use the customer-reported 4. ACS data forrent housing costs associated with costs based on zip code their creditcard applications. 4. In the absence of 1, 2, and 3, use the ACS rentestimates based on customer's zip code. 5. If no data is available, setto null. Utilities 1. User-augmented data is N/A DEFAULT N/A DEFAULTY 1. User Input used whenever available. 2. Transactions 2. In theabsence of designated as utilities augmented data, median from Financialmonthly costs based on institution and card transaction history of last12 accounts. Perform the months of bank and/or card categorization basedon data is used. MCC. 3. If no values available, value set to null.Trans- General 1. Median monthly costs N/A DEFAULT N/A DEFAULT N 1.Transactions related portation Transport based on transaction history ofto general transportation last 12 months of bank and/or costs fromFinancial card data. institution and/or card 2. If no data available,set to accounts. Perform the null categorization based on MCC. Auto 1.If IFM auto payment data is N/A STDDEV N/A DEFAULT N 1. Transactionsrelated available, it is used. to auto payments from 2. In the absenceof 1, the Financial institution maximum value of the accounts mined byIFM. monthly auto payments 2. Auto Payments from reported by Equifax,the three credit bureaus- Experian, and TransUnion is Equifax, Experian,and used. TransUnion. 3. In the absence of 1 and 2, 3. Transactionsrelated the median monthly costs to auto from Financial based ontransaction history of institution and/or card last 12 months of bankand/or accounts. Perform the card data is used. categorization based on4. If no values available, set to MCC. null. Combined 1. User-augmenteddata is MIT WEIGHTED DEFAULT DEFAULT Y 1. User Input used wheneveravailable. 2. Combination of 2. If General Transport and/or GeneralTransport Auto costs calculated above and/or Auto Costs are available,combine these 3. COL data for values. Transportation costs 3. In theabsence of 1 and 2, based on MIT Living COL estimates from MIT Wageestimates for a Living Wage data for a single single person in personmay be used. customer's zip code 4. If no values available, set to null.Food 1. User-augmented data is MIT DEFAULT DEFAULT DEFAULT Y 1. UserInput used whenever available. 2. Transactions related 2. In the absenceof to Food from Financial augmented data, median institution and cardmonthly costs based on accounts. Perform the transaction history of last12 categorization based on months of bank and/or card MCC (Merchant datais used. category Codes). 3. In the absence of 1 and 2, 3. COL data forfood COL estimates from MIT costs based on MIT Living Wage data for asingle living wage estimates for person may be used. a single person in4. If no values available, value customer's zip code. set to null.Medical 1. User-augmented data is MIT DEFAULT DEFAULT DEFAULT Y 1. UserInput used whenever available. 2. Transactions related 2. In the absenceof to Medical expenses augmented data, median from Financial monthlycosts based on institution and card transaction history of last 12accounts. Perform the months of bank and/or card categorization based ondata may be used. MCC (Merchant 3. In the absence of 1 and 2, categoryCodes). COL estimates from MIT 3. COL data for Medical Living Wage datafor a single costs based on MIT person may be used. living wageestimates for 4. If no values available, value a single person in set tonull. customer's zip code Childcare 1. User-augmented data is MITDEFAULT N/A DEFAULT Y 1. User Input used whenever available. 2.Transactions related 2. In the absence of to Childcare from augmenteddata, median Financial institution and monthly costs based on cardaccounts. Perform transaction history of last 12 the categorizationbased months of bank and/or card on MCC (Merchant data may be used.category Codes). 3. In the absence of 1 and 2, 3. COL data for COLestimates from MIT Childcare costs based on Living Wage data for asingle MIT living wage person, which is $0.00 for estimates for a singlechildcare may be used. person in customer's zip 4. If no valuesavailable, value code. For Childcare, this set to null. value is $0.00.Tax 1. User-augmented data is MIT DEFAULT DEFAULT DEFAULT Y 1. UserInput used whenever available. 2. Transactions related 2. In the absenceof to Tax expenses from augmented data, median Financial institution andmonthly costs based on card accounts. Perform transaction history oflast 12 the categorization based months of bank and/or card on MCC(Merchant data may be used. category Codes). 3. In the absence of 1 and2, 3. COL data for Tax COL estimates from MIT costs based on MIT LivingWage data for a single living wage estimates for person may be used. asingle person in customer's zip code 4. If no values available, valueset to null. Insurance 1. User-augmented data is N/A DEFAULT N/A DEFAULTY 1. User Input used whenever available. 2. Transactions related 2. Inthe absence of to Insurance expenses augmented data, median fromFinancial monthly costs based on institution and card transactionhistory of the last accounts. Perform the 12 months of bank and/or cardcategorization based on data may be used. MCC (Merchant 3. If no valuesavailable, value category Codes). set to null. 3. COL data for Insurancecosts based on MIT living wage estimates for a single person incustomer's zip code Debt Student 1. User-augmented data is N/A N/AN/A 1. Set to Y 1. User Input Payment Loan used whenever available. 1.0for 2. Monthly Student Loan Payments/ 2. In the absence of 1, the user-payment reported from Balance monthly student loan augmented Experian.payments reported by data. Experian may be used. 2. 3. If no valuesavailable, set to Otherwise null. set to 0.0. Credit 1. The minimummonthly N/A N/A N/A 1. Set to N 1. Credit card minimum Card paymentreported by internal 1.0 if use monthly payments from Minimum Card datais used. internal internal data. Payment 2. In the absence of 1, valueis card data. set to null. 2. Otherwise set to 0.0. External 1.User-augmented data is N/A N/A N/A 1. Set to Y 1. User Input Credit usedwhenever available. 1.0 for 2. Minimum monthly Card 2. In the absence of1, user- payments reported by Minimum reported monthly minimum augmentedTransUnion. Payment payments on up to 7 data. bankcards from TransUnion2. may be used. Otherwise 3. In the absence of 1 and 2, set to 0.0.value is set to null. Committed Monthly 1. User-augmented data is MITWEIGHTED DEFAULT DEFAULT Y 1. User Input Expenses used wheneveravailable. 2. Costs listed above. 2. In the absence of 1, this 3. COLdata for total value is the sum of all the living costs based onindividual costs that make up MIT Living Wage a customer's CME, listedestimates for a single above. person in customer's zip 3. In the absenceof 1 and 2, code. COL estimates from MIT Living Wage data for a singleperson may be used. 4. If no values are available, set to null. SPENDTotal Monthly Spend 1. User-augmented data is N/A DEFAULT N/A DEFAULTY 1. User Input used whenever available. 2. All debits from 2. In theabsence of 1, take the customer bank and card sum of the median monthlyaccounts. debits on a customer's card and bank accounts. 3. In theabsence of 1 and 2, value is set to null. Flexible Monthly Spend 1.User-augmented data is N/A WEIGHTED N/A DEFAULT Y 1. User Input usedwhenever available. 2. Committed Monthly 2. If Total Monthly Spend andExpenses and Total CME values are available, Monthly Spend calculatethis as the difference estimates listed above (Total Monthly Spend-CME)3. In the absence of 1 and 2, value is set to null. INCOME IncomeAnnual 1. User-augmented data is MIT N/A If uses CC DEFAULT Y 1. UserInput Gross used whenever available. application 2. Customer-suppliedIncome 2. In the absence of 1, the or TALX income from Credit Cardincome supplied by a data, takes Applications customer during theircredit the average 3. TALX Income from card application is used. Use ofthe Bank data only data provided within the default 4. MIT Living Wagelast three years and scale it up reasonable- estimates for gross by 3%per year. ness score income for a single 3. In the absence of 1 and 2,and the person in customer's zip TALX income from internal Ability tocode Bank sources is used. Pay (ATP) 5. ACS Gross Income 4. In theabsence of the above reasonable- per capita. values, gross incomeestimates ness score. from the MIT Living Wage The ATP data is used.score 5. If none of the above are utilizes available, the ACS values ofemployment gross income per capita is and used. FICO data 6. If none ofthe above are to available, value set to null. determine whether or nota customer's reported income is viable (e.g.,. if a customer is listedas Employed with a FICO Score below 600, ATP does not expect an incomehigher than $100,000. Net 1. User-augmented data is MIT 1. If usingDEFAULT DEFAULT Y 1. User Input Monthly used whenever available.customer's 2. Salary data from IFM Income 2. In the absence of 1, salarytax and 3. Annual Gross Income information from IFM is used. medical 4.Tax and Medical 3. In the absence of 1 and 2, costs, use the Costsleverage a customer's tax and WEIGHTED 5. Transactions related medicalcosts in conjunction variability to deposits in Financial with acustomer's Gross score from institution accounts Income is used. If thethese values. 6. MIT Living Wage reasonableness score of tax 2. If usingestimates for net income and/or medical costs is greater median for asingle person in than 0.5, assume that these monthly customer's zip codecosts are not taken out of credits, customer's pay. Thus, monthlyDEFAULT Gross and Net Income are variability comparable. score. 4. Ifthe reasonableness scores for tax and/or medical are below 0.5, thissuggests that these payments are automatically withdrawn from acustomer's pay. The MIT Living Wage estimates to determine customer'sexpected costs of insurance and tax and deduct this from their GrossIncome to determine Net Income is used. 5. If the MIT data isunavailable, assume that medical costs are 5% of Gross Income and taxcosts are 22%. Deduct these amounts from Gross Income to estimate NetIncome. 6. In the absence of augmented values or Gross Income, themedian monthly credits into a customer's bank accounts may be used. 7.In the absence of above values, the net income estimates from the MITLiving Wage data may be used. 8. If none of the above are available, setto null Monthly 1. User-augmented data is 50% of Net WEIGHTED DEFAULTDEFAULT Y 1. User Input Discretionary used whenever available. Monthly2. Net monthly income Income 2. In the absence of Income and CMEdetermined in augmented data, calculate the steps above. discretionaryincome as Net Monthly Income-CME. 3. In the absence of CME, thebenchmark value of 50% of Net monthly Income as discretionary income isused. 4. If no values available, value set to null. ASSETS Liquid 1. Thetotal balance in a IXI N/A DEFAULT DEFAULT N, 1. Financial institutionAssets customer's personal Financial Cus- checking and savingsinstitution checking and tomer account balances. savings accounts may beused. can 2. User augmented data 2. Customers can augment. aug- onassets earmarked for 3. In the absence of 1 and 2, ment emergencies. IXIestimates for liquid assets their 3. IXI data for customer's may beused. Exter- savings estimate. 4. If no values available, value nal setto null. Assets and Inter- nal assets inten- ded for emer- gen- ciesEMERGENCY FUND Emergency Fund Shortfall 1. In they have less than 1 N/AN/A N/A Average of (Y) 1. User Input. Note that CME saved up, theirshortfall CME and while the GE can is their CME-Liquid Assets. Liquidcurrently accept 2. If they have less than 3 Assets augmented shortfallCME saved up, their shortfall confidence values. is (3*CME-LiquidAssets.) scores 2. Liquid Assets and 3. If they have < 6 CME the CME todetermine the value is set to (6*CME- shortfall identified by LiquidAssets). the FBP Standard 4. If they have > 6 CME saved up, theshortfall is 0. Emergency Fund Save Rate 1. If customer is eligible forN/A N/A N/A 1 (Y) 1. User Input. Note that Emergency Savings alone, thewhile the GE can FBP Standard recommended currently accept value of 10%is used. augmented savings rate. 2. If they are eligible for both 2.Liquid Assets, CME High Interest Debt Paydown and Debt values to as wellas Emergency determine the FBP Savings, the 10% is split Standardbetween them equally. recommendation. 3. If they are not eligible for asavings recommendation, it is set to 0%. Emergency Monthly 1. IfDiscretionary income and N/A N/A N/A N/A N 1. Discretionary Income FundPayments Emergency Fund save rate are and Emergency Fund Timescale allavailable, determine a Save rate estimated in customer's recommendedsteps above. monthly saving amount by simply multiplying the save rateby their discretionary income: (EF save rate * discretionary) 2. If noneof the above combinations are available, the monthly payment is set tonull. Timescale 1. If Emergency Fund N/A N/A N/A AVERAGE N 1. MonthlyPayments Shortfall and Monthly of and Emergency Fund Payments are allnon-null, the confidence Shortfall values timescale is calculated as:scores of estimated in steps above. EF Shortfall/ Monthly DiscretionaryPayments. Income 2. If none of the above and EF combinations areavailable, Shortfall the timescale is set to null. HIGH INTEREST DEBTHigh Debt The revolving debt principal N/A N/A N/A 1 N 1. Average DailyInterest Principal that was not paid off by the Balance from card Debtcustomer, which is the statements table for a interest-bearing componentof customer. credit card debt. APR The interest rates on the N/A N/A N/A1 N 1. APR designated for Credit Card. Credit Card purchases Minimum Theminimum payment that a N/A N/A N/A 1 N 1. Minimum Payment Paymentcustomer has to make each pulled from internal card cycle towards theircredit card statements table. debt. Cost to The total cost that acustomer N/A N/A N/A 1 N 1. Minimum payment Paydown would have to spendif they costs pulled from Making paid off their current debt internalcard statements Minimum using the minimum payments table. Payments only.Time to The total time that it takes a N/A N/A N/A 1 N 1. Minimumpayment Paydown customer to pay off their debt time pulled from internalMaking if they make the minimum card statements table. Minimum paymentsonly. Payments External Debt 1. User-augmented data is N/A N/A N/A Ifuser Y 1. Prioritize customer High Principal used whenever available.augments, augmented data here, but Interest 2. If 1 is not available,the set to 1.0. also have a current Debt current balance for the cardOtherwise balance due from reported by Trans Union is set to 0.0.TransUnion for up to 7 used. cards. APR The interest rates on the N/AN/A N/A If user Y 1. User Inputs/ External Credit Card. augments,Augmented only. set to 1.0. Otherwise, set to 0.0. Minimum The minimumpayment that a N/A N/A N/A If user Y 1. Augmented data is Paymentcustomer has to make each augments, used whenever possible. cycletowards their credit card set to 1.0. 2. If augmented data is debt.Otherwise, not available, minimum set to 0.0. payment information fromTransUnion for up to 7 individual cards is used HIGH INTERESTDEBT-CALCULATIONS Pay Rates Debt Pay Payrate is a percentage of N/A N/AN/A 1 Y Defined by the FBP Rate discretionary income between Standard 0and 10% depending on recommendation. customer's financial state. Debt_Recommended Combination of the minimum N/A N/A N/A Debt N 1. Minimumpayments, <STRA- Monthly payments and the percentage balancediscretionary income, TEGY> Payments of discretionary income FBP ratioand Debt Payrate. <DEBT Standard dictates customer TYPE> use for DebtPaydown Timescale 1. Using the recommended N/A N/A N/A Debt N 1. Debtprincipal, monthly payments and balance Monthly Payments, APR estimateof total debt, ratio calculate the number of months required to paydowndebt. Total Cost The total cost combines the N/A N/A N/A Debt N debtprincipal with the interest balance owed for each of the various ratiodebt accounts. Interest The total Interest cost for N/A N/A N/A Debt NPaid customer using this paydown balance strategy ratio Strategy PaydownStrategy used N/A N/A N/A N/A N Avalanche/Snowball/ Minimum APR Paydowncalculations done N/A N/A N/A N/A N 0 or 7 Cutoff for either HID (>7%APR) or All debts (>=0% APR) Debt Dictionary of each of the N/A N/A N/AN/A N Accts associated debt accounts, their paydown timescales, cost,interest cost, etc. Lump Total 1. User-augmented data is N/A N/A N/ADebt Y 1. User Inputs. Payment Lump used whenever available. balance 2.Emergency Fund, (for Payment 2. If they have less than < 3 ratio DebtPaydown times and Minimum/ CME saved up or < 3 months Liquid assets toSnowball/ of payable debt, then it is set determine the FBP Avalanche to0. Standard. Strategies) 4. If they have > 3 CME and > 3 months ofpayable debt, the value is set to Liquid Assets- 3*CME. (Bringing themdown to 3 CME of savings). Debt Dictionary of each of the N/A N/A N/AN/A N Accts associated debt accounts, their paydown timescales, cost,interest cost, etc. Has the lump payment amount devoted to each accountbased on paydown Strategy Remainder is the same as Debt _ <STRATEGY><DEBTTYPE> Debt HID Compares the Cost and Time N/A N/A N/A Debt N Costdifference between all balance Time different paydown strategies ratioSavings for High Interest Debt All Compares the Cost and Time N/A N/AN/A Ratio of N difference between all balances of different paydownstrategies Debt with for All Debt information to all Debts

Income: The guidance engine determines multiple variations on acustomer's income and that may include gross income, net income, anddiscretionary income. Gross income is defined as a customer's annualpre-tax income. Data sources for this value are prioritized as follows:

-   -   customer-augmented values;    -   gross income disclosed in credit card applications from up to 3        years ago, where if the customer-reported income is more than 1        year old, it may be scaled up, e.g., by 3% per year, to account        for annual increases in salary;    -   TALX Projected Income defined as payroll data purchased from        Equifax and sourced from employers that is updated every 6        months, but limited to customers required to show        proof-of-income;    -   MIT Living Wage estimates of minimum gross income for customer's        county;    -   ACS estimate of gross income per capita; and    -   if none of the above are available, the value is set to null.

Net income is a customer's monthly income post any deductions (e.g.,tax, medical insurance, wage garnishment). Data sources for this valueare prioritized as follows:

-   -   customer-augmented values;    -   net salary data from third party sources;    -   gross income as described above, using estimates of tax and        medical costs for each customer, gross annual income can be        transformed into net monthly income;    -   median monthly credits posted to customer's bank accounts, where        each customer's accounts over the previous year may be used to        estimate the typical monthly deposits;    -   MIT living wage estimates of minimum net monthly Income for        customer's county; and    -   if none of the above are available, the value is set to null.

Finally, each customer's discretionary income may be calculated wherethe outstanding amount of net monthly income available after a customerhas covered their committed monthly expenses. In other words:

Discretionary Income=Net Monthly Income−CME

Emergency Fund: The guidance engine examines each customer's emergencyfund, e.g., the amount of liquid assets available to cover CommittedMonthly Expenses should something unexpected happen. This analysis mayinclude the following data points:

-   -   Liquid Assets. For each customer, the funds available in a        customer's personal accounts, for example, a customer's checking        and savings account, are combined. Note that amounts can be from        a prior period and may undergo volatility. Customers have an        opportunity to augment this value via the guidance engine API,        specifying a specific subset of the balance that can be used in        an Emergency. Additionally, customers can leverage augmentation        to inform the guidance engine about other liquid assets that can        be used in an emergency.    -   Committed Monthly Expenses, a customer's must-pay monthly        expenses, as previously described above.    -   Discretionary Income, the amount of net monthly income left over        once a customer has taken care of their CME, described above.

For each customer, the guidance engine calculates/returns the following:

-   -   Emergency Fund—the number of Months of CME saved as Liquid        Assets.

${EF} = \frac{{Liquid}{Assets}}{CME}$

-   -   Emergency Fund Savings Goal—this monetary value is defined by        the FBP Standard. Depending on a customer's financial picture,        this goal is 1, 3, or 6 months of CME.    -   Emergency Fund Shortfall—the amount a customer needs to save to        reach their Emergency Fund goal identified by the FBP Standard

EF Shortfall=EF Goal−Liquid Assets

-   -   Emergency Fund Save Rate—the percentage of a customer's        discretionary income the FBP Standard recommends they allocate        towards their Emergency Fund. This value varies from 0 to 10%.    -   Emergency Fund Timescale—the number of months required by        customer to achieve their Emergency Fund goal if they save the        recommended amount per month

$\frac{{EF}{Short}{fall}}{{EF}{Save}{Rate}*{Discretionary}{Income}}$

High Interest Debt (HID): In addition to Emergency Fund, the guidanceengine may also provide advice to customers on how to tackle their HighInterest Debt. HID is defined as any loan with an interest rate above athreshold rate, for example. 7% and higher. The threshold rate is setsuch that the guidance engine Debt component may focus on high interestrevolving Credit Card debt.

As previously explained, a dictionary of revolving card debt accounts,with information on minimum payments, revolving balance, etc. isorganized on an account-by-account basis. In addition to a customer'shigh interest debt, information about other debts the customer may have,such as mortgages, auto loans, and student loans may also exist. Thisinformation comes from at least the credit bureaus. Within the guidanceengine this information can be added to the card debt dictionary,creating a single dictionary that contains information on eachcustomers' total debt load. As with the card debt accounts, customerswill be able to augment these values via the guidance engine API,providing the opportunity to learn about their interest rates, etc.without requiring them to aggregate.

Combining all debts into a single dictionary provides the ability todetermine paydown times/costs for high interest debt and all debts withthe same codebase. It also provides a foundation for how to integratedebt accounts that customers disclose via aggregation. Note that if adebt account in a dictionary is missing some critical values (e.g., APR,revolving balance, minimum payment), it cannot include it in a debtaccount calculation. Thus, augmentation is critical to debtcalculations.

Utilizing the dictionary of debt accounts, the guidance engine maycalculate the following:

-   -   Total Debt Principal—the combination of revolving balances on        which interest is charged that can be distinguished as High and        Low interest debt;    -   Debt Paydown Rate—the percentage of a customer's discretionary        income the FBP Standard recommends they allocate towards paying        down High Interest Debt that can vary from 0 to 10%;    -   Monthly Payments—the sum of a customer's current total minimum        payments and the amount associated with their debt paydown rate        that may be calculated as:

Minimum Payment+(Debt Pay Rate*Discretionary Income)

-   -   Cost and Time to paydown debt based on one of many various        paydown strategies—the guidance engine may calculate values        based on different priorities. For example, tackling debt with        the highest interest rate first or by paying down debt with the        smallest revolving balance first. For both of these strategies,        once a debt is paid down, the monthly payments associated with        it rolls over to help customers pay down the next debt. For        Minimum payment, customers pay only their current minimum        payment due on a debt, and the amounts don't roll over between        accounts. While a customer's minimum payment due decreases as        their balance decreases, the protocol for defining a minimum        payment varies dramatically with the debt issuer, making it        difficult to accurately calculate; consequently, the current        value may be used, rather than having the minimum payment        decreasing over time.    -   Lump Payments—If a customer has a High amount of high interest        debt and more than 3 months' worth of CME in liquid assets, they        are eligible to make a Lump Payment towards their High Interest        Debt. This value is calculated as follows:

Lump Payment=Liquid Assets−(3*CME)

-   -   Lump payment options may be integrated into all of the different        paydown strategy calculations, allotting lump payments according        to tackling debt with the highest interest rate first or by        paying down debt with the smallest revolving balance first        strategies and outputting the amount devoted to each individual        debt account. Whether customers want to devote lump payments to        high interest debt alone or all of their various debt accounts        may also be modeled.    -   Cost and Time Savings—For each customer, the total cost and time        required to paydown debt across the different available        strategies are compared. This allows customers to make an        informed decision about which strategy will work best for them.

Confidence Scores: The guidance engine API encourages customers tocorrect guidance engine financial estimates when they are inaccurate. Intandem with this, a metric called Confidence scores also exists, whichprovides a quantitative way to measure the relative accuracy of anyestimated values and recommendations. Consisting of two components, aReasonableness Score and a Variability Score, Confidence Scores rangefrom 0, where there is no confidence, to 1, where there is a strongbelief that the estimated values are accurate. It may also factor indata sourcing information, prioritizing augmented, internal, andexternal data in that order. Every value output by the guidance enginehas an associated Confidence Score.

Initially, Confidence Scores provide a valuable metric to prioritizefurther guidance engine work. For example, if customers are changingvalues by a significant amount that were initially were held in highconfidence, those estimates need to be improved.

Reasonableness Score: This score is a measure of how reasonable guidanceengine values are and how close those values are to a benchmark value.For example, a benchmark source is the MIT Living Wage Cost of Livingdata, associated with a customer's location and assuming a single adultliving on their own with no dependents. Another benchmark source isthird-party data, e.g., external data from IXI and ACS. And, yet anotherbenchmark source is the use of financial guidelines, for example, acustomer's discretionary income should be about half their net monthlyincome. Unreasonable values have scores close to 0; those that arereasonable are close to 1.

-   -   1. When the estimated value is smaller than the benchmark, the        reasonableness score is the ratio of the estimated value to the        COL estimate. The smaller the value, the smaller the        reasonableness score.    -   2. When the calculated value is between 1 and 3 times the        benchmark estimate, the reasonableness score is set to 1.        Benchmark values are based on a single adult with no dependents.        By expanding the acceptable range of benchmark values, the        guidance engine can better account for customers hailing from        all types of households.    -   3. When the calculated value is greater than 3 times the        benchmark estimate, the reasonableness score is degraded, as the        calculated value seems excessively high. The score is then        defined as the ratio of the benchmark estimate to the estimated        value; the larger the estimated value, the smaller the        reasonableness score.    -   4. In the absence of benchmark estimates, the value is set to        null.

A summary of the Reasonableness Score formula is below:

${{Reasonableness}{Score}} = \left\{ \begin{matrix}\frac{value}{benchmark} & {{value} < {benchmark}} \\1. & {{benchmark} < {value} < {3*{benchmark}}} \\\frac{benchmark}{value} & {{value} > {3*{benchmark}}}\end{matrix} \right.$

Variability Score: When a particular value exhibits large amounts ofvariation (e.g., over time, between bureaus, etc.), there is lessconfident in the accuracy of the guidance engine estimates. Thisconfidence is quantified as the Variability Score, which reflects thevolatility of the estimated value. The general protocol is as follows:

-   -   1. When possible, the IQR is estimated for each component of the        calculation. For data points that are not variable over time,        other measures may be used. For example, rather than IQR, the        standard deviation across the credit bureaus may be used to        estimate the variability of a customer's total monthly mortgage        payments. Due to the low number of points included in the        standard deviation, the sample standard deviation is utilized        rather than the population standard deviation. Additionally, IQR        and standard deviation cover a different percentage of the        distribution. Thus, all calculations are scaled using standard        deviation by a factor or 1.348, such that it better reflects 50%        of the sample and is comparable to IQR.    -   2. The variability score is calculated as:

$1 - \frac{IQR}{value}$

-   -    where value is the amount calculated by the Guidance Engine in        the given category and, when IQR is not available, same formula        with standard deviation may be used.    -   3. If the Variability Score is negative, meaning that the IQR is        larger than the value, it is set to 0.0.    -   4. In the absence of IQR, or an analogous measure of variation,        the Variability Score is null. The basic formula is summarized        below:

${{Variability}{Score}} = \begin{Bmatrix}{1 - \frac{IQR}{value}} & {0 < {{var}{score}} < 1} \\0 & {{{var}{score}} < 0}\end{Bmatrix}$

-   -   5. For some initial calculations, data from multiple sources is        combined (e.g., using transaction data from both financial        institutions and credit cards to calculate categorized costs).        To determine the variability of the total value, the square root        of the sum of squares for each component is calculated:

√{square root over (IQR _(a) ^(□) ² +IQR _(b) ^(□) ² )}

-   -   6. When multiple components are combined for certain        calculations (e.g., CME is a combination of Food, Medical,        Housing costs, etc.), their variability scores are weighted to        determine the variability score for the final value. This        protocol factors in the level of importance for each component,        ensuring that the final confidence scores are penalized when        large values are highly variable. The formula is as follows:

$\frac{\left( {{Value}_{a}*{Var}{Score}_{a}} \right) + \left( {{Value}_{b}*{Var}{Score}_{b}} \right)}{\left( {{Value}_{a} + {Value}_{b}} \right)}$

-   -   Confidence score: The Confidence score is a unified measure of        the Variability and Reasonableness Scores. It quantifies an        overall confidence in the accuracy of each guidance engine        output. This score is calculated using the following steps:    -   1. When there is both a Variability and Reasonableness Score,        the Confidence Score is the average of the two.    -   2. If there is only the Variability Score, the Confidence Score        equals the Variability Score. There is no penalty for a lack of        Reasonableness Scores as benchmarks are not always available and        variability is in closer proximity to the data itself.    -   3. If there is only the Reasonableness Score, the Confidence        Score is set to one half of the Reasonableness Score estimate        (to penalize the lack of Variability Score).    -   4. If neither score is available, the value is set to 0.    -   5. If the data point came from external, rather than internal        data, the confidence score is set to 0.0.    -   6. If the data point came directly from Augmented data, the        confidence score is set to 1.0.

Note that a different technique may be used to calculate confidencescores for the debt calculations. If some critical information is absentfor various debt accounts, those cannot be included in the calculations.The debt confidence scores are the ratio of the debt balances where theneeded information is present to those that are not present. Forexample, if there are 3 debt accounts of $1000, $5000, and $10000, butthe necessary information is only present for only the $10000 account,the confidence score will be (10000)/(1000+5000+10000)=0.625. If theinformation is present for only the $1000 account, the confidence scorewill be (1000)/(1000+5000+10000)=0.0625, as there is less confidence inthe paydown calculations due to a lack of information. Note that thismay result in some very low confidence scores for individuals withmortgages, auto loans, student loans.

Decision Tree: Once the Inputs component is complete, its output may bepassed to the decision tree component of the guidance engine. Thisportion identifies each customer's financial recommendation, based on anin-house FBP Standard. It outlines the recommended pathway for acustomer to become financially healthy and eligible to invest. In anembodiment, the FBP Standard focuses on helping customers build up theiremergency fund and pay down their high interest debts.

The guidance engine may use the following data points in the DecisionTree:

-   -   Emergency Fund—Number of Months of CME saved up in Liquid Assets    -   High Interest Debt—High Interest Debt Pay-down Timescale        utilizing the strategy that encourages customers to tackle debt        with the highest interest rate first    -   Discretionary Income—Amount customer has to spend once they have        taken care of CME

For each customer, each value is compared to benchmark values. For theEmergency Fund, the following benchmark amounts may be used:

-   -   Invalid value—guidance engine is unable to calculate a        customer's emergency fund as it lacked necessary data elements.    -   <1 CME—Customer needs to prioritize saving over all other goals.    -   1-3 CME—Customer needs to save more for their Emergency Fund but        can also pay down any high interest debt with recurring payments        in parallel.    -   3-6 CME—Customer needs to save more for their Emergency Fund but        can also pay down any high interest debt with Lump payments        and/or recurring payments in parallel.    -   >6 CME—Barring no high interest debt, customer is ready to        invest.

For high interest debt, benchmarks based upon timescales may be used foreach customer to pay down their debts:

-   -   Invalid value—when the guidance engine is unable to calculate a        customer's High Interest Debt due to the absence of a necessary        data element;    -   Zero debt—No Revolving High Interest Debt    -   <3 Months to pay down debt—Moderate Revolving High Interest        Debt, which a customer can pay off with recurring payments if        applicable.    -   >3 Months to pay down debt—High Revolving High Interest Debt,        which the customer can pay off with Lump payments and/or        recurring payments if applicable.    -   These benchmarks are compared with the time required for a        customer to pay down their high interest debt (anything with an        APR greater than 7%) using the strategy that encourages        customers to tackle debt with the highest interest rate first        and devoting 5-10% of their discretionary income to monthly        payments, in addition to the minimum payments.

For discretionary income, determination needs to be made as to whetheror not the guidance engine can provide constructive guidance forcustomers. Specifically, if the customer has no money left over afterthey pay for critical monthly expenses, they cannot allocate funds totheir Emergency Fund or pay down High Interest Debt. Thus, the followingbenchmarks may be used for discretionary income:

-   -   Invalid value—guidance engine is unable to calculate        Discretionary Income as lacking necessary data elements    -   No Discretionary Income—Customer's calculated Discretionary        Income is less than or equal to zero, due to CME being greater        than or equal to their Net Monthly Income    -   Valid Discretionary Income—Customer's calculated Discretionary        Income is greater than zero.

Note in the benchmarks above that when faced with data gaps the guidanceengine will still provide a recommendation based on the limitedinformation it does have, while also indicating data insufficiency.

-   -   If Discretionary Income data is unavailable, “NeedDisclncome” is        included in the Recommendation.    -   If Emergency Fund data is unavailable, “NeedAssets” is included        in the Recommendation.    -   If High Interest Debt data is unavailable, “NeedDebt” is        included in the Recommendation.    -   If both are unavailable, the guidance engine returns        “NeedAssets_NeedDebt” as the only recommendation.

A summary of the Guidance Engine recommendations, based on datasufficiency and a customer's location in the FBP Standard, is shown inTable 3 below:

TABLE 3 Guidance Engine Recommendations High Interest DiscretionaryRecommendation Emergency Fund Debt Income NeedAssets_NeedDebt N/A N/AN/A NeedDiscIncome Any Value Any Value N/A NoDiscIncome Any Value AnyValue ≤0 0to1CMESaveMore <1CME Any Value >0 1to3CMESaveMore 1 CME < EF <3 CME None >0 1to3CMESaveMore_PayDownModerateDebt 1 CME < EF < 3 CME <3Months to >0 Paydown 1to3CMESaveMore_PayDownHighDebt 1 CME < EF < 3CME >3 Months to >0 Paydown 1to3CMESaveMore_NeedDebt 1 CME < EF < 3 CMEN/A >0 3to6CMESaveMore 3 CME < EF < 6 CME None >03to6CMESaveMore_PayDownModerateDebt 3 CME < EF < 6 CME <3 Months to >0Paydown 3to6CMESaveMore_PayDownHighDebt 3 CME < EF < 6 CME >3 Monthsto >0 Paydown 3to6CMESaveMore_NeedDebt 3 CME < EF < 6 CME N/A >0InvestingReady EF > 6 CME None >0 PayDownModerateDebt EF > 6 CME <3Months to >0 Paydown PayDownHighDebt EF > 6 CME >3 Months to >0 PaydownNeedDebt EF > 6 CME N/A >0 NeedAssets N/A None >0NeedAssets_PayDownModerateDebt N/A <3 Months to >0 PaydownNeedAssets_PaydownHighDebt N/A >3 Months to >0 Paydown

Outputs

The final outputs of the guidance engine include both the calculatedvalues, accuracy metrics, origin flags, and final recommendations. Foreach of the output categories return origin flags are generated,indicating where the data originated, variability, reasonableness, andconfidence scores, and the estimated value.

Method

FIG. 4 depicts a flow chart of an example method 400 for a guidanceengine to provide an automated method for providing financial guidance,according to one or more aspects of the disclosure. In step 410, inputdata is collected for a user or customer. The input data focuses on thatuser's expenses on a monthly bases, their income, an emergency fundlevel and the amount of high interest debt. Input data can exist withina financial institution, especially if the user is a customer of thatfinancial institution. Internal input data can include banking relateddata, such as the balances in a user's checking and savings account.Internal input data can also include credit card data includingbalances, credit limits, annual percentage rates, minimum payments andthe like. Internal input data can also include credit bureau data, suchas data from Equifax, Experian and TransUnion. Input data can alsooriginate from external data sources such as cost of living estimatesfrom the Massachusetts Institute of Technology Living Wage Estimates andthe American Community Survey data. Thus, input data can consist ofactual user data and from external sources, which are primarily usedwhen internal or user supplied data is unavailable.

At step 420, an initial calculation is may be performed on the inputdata gathered in step 410. The initial calculation may includetransforming the data into standardized formats for compatibility and tooptimize and integrate the data used for a given customer based onavailability to ensure the best data available for each customer.Ensuring the best data available is also referred to as dataoptimization. The initial calculation is directed to calculating anestimated committed monthly expenses level of the user. It is also usedto estimate the monthly income of the user. The committed monthlyexpenses is defined as the total monthly fixed expenses incurred by thecustomer to cover their essential needs. These needs include items suchas childcare, credit card minimum payments, food, housing insurance,medical, phone, loan payments, taxes, transportation, utilities and thelike.

Monthly income may include calculating gross income, net income, anddiscretionary income. Gross income is defined as the customer's annualpre-tax income. Net income is a customer's monthly income less anydeductions such as taxes, insurance, and garnishments. Discretionaryincome is defined as the outstanding amount of net monthly incomeavailable after a customer has covered their committed monthly expenses.

At step 430, an intermediate calculation is made to determine anestimated emergency fund level and an estimated high interest debt levelof the customer. A customer's emergency fund is defined as the amount ofliquid assets they have available to cover committed monthly expensesshould something unexpected happen. Further, the estimated high interestdebt level comprises a loan with an interest rate above a pre-setthreshold, e.g., above 7%. This analysis utilizes the level of liquidassets of the customer, their committed monthly expenses, the amount ofdiscretionary income. Further, the customer can also have an emergencyfund savings goad that is defined by the FBP standard where the goal is1, 3 or 6 months of committed monthly expenses.

At step 440, a confidence score and variability score is generated foreach of the estimated values, including the committed monthly expenses,monthly income, emergency fund level and high interest debt level. Aconfidence score provides a quantitative method to measure the relativeaccuracy of the estimated value and recommendations. A confidence scoreconsists of two components, a reasonableness score and a variabilityscore. Confidence scores range from 0, indicating no confidence, to a 1,where there is complete confidence that the values are accurate. Theconfidence also factors in the source of the data that is prioritized asbeing augmented, internal, and then externally sourced.

The reasonableness score is a measure of how reasonable the guidanceengine estimated values are, or how close are the estimated values to abenchmark value. The benchmark values come from external sources such asthe MIT Living Wage Cost of Living data, or the American CommunitySurvey. As discussed above, a summary of the reasonableness scoreformula is as follows:

${{Reasonableness}{Score}} = \left\{ \begin{matrix}\frac{value}{benchmark} & {{value} < {benchmark}} \\1. & {{benchmark} < {value} < {3*{benchmark}}} \\\frac{benchmark}{value} & {{value} > {3*{benchmark}}}\end{matrix} \right.$

The variability score indicates the amount of variation, either overtime or between different sources and reflects the volatility of anestimated value. The variability score is based on the interquartilerange (IQR) amount for each component of the calculation and iscalculated as follows:

$1 - \frac{IQR}{value}$

where “value” is the amount calculated by the guidance engine in thegiven category. Also, if the IQR is not available, the same formula maybe used, but with standard deviations.

At step 450, the financial situation of the user is categorized based onthe user's estimated emergency fund level and the estimate high interestdebt level. The categorization may use a financial best practicesstandard to suggest a next financial action step. A summary of theactions associated with the various levels of emergency fund and highinterest debt load are reproduced below:

Emergency High Interest Debt Load Fund None Moderate High <1 CMECustomer needs to save a baseline level of 1 CME in liquid assets beforeconsidering other financial goals. <3 CME Customer Customer shouldallocate funds to either Emergency Fund, Debt should save Paydown, orboth. 3 CME. <6 CME Customer Customer should pay down Customer shouldpay down debt should save debt with recurring payments. with lump and/orrecurring 6 CME. They are also eligible to save payments. They are alsoeligible for Emergency Fund. to save for Emergency Fund. >6 CME Customeris Customer should pay down Customer should pay down debt ready to debtwith recurring payments with lump and/or recurring Invest. payments

A “none” level of high interest debt load is defined as a customer withno revolving debt. A “moderate” level of high interest debt load isdefined as a customer with revolving debt that takes less than 3 monthsto pay down with recurring payments of approximately 5-10% of acustomer's discretionary income on top of their minimum payment for thatrevolving debt. And, a “high” level of interest debt load is defined asa customer with revolving debt that takes greater than 3 months to paydown with recurring payments of approximately 5-10% of a customer'sdiscretionary income on top of their minimum payment for that revolvingdebt. The method then ends.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A system comprising: a data integration enginecomprising: one or more first processors; and first memory storing firstinstructions that, when executed by the one or more first processors,cause the data integration engine to: determine user data associatedwith an estimated monthly expenses of a user, an estimated monthlyincome of the user, an estimated emergency fund level of the user, andan estimated high interest debt level of the user; and a decision treeengine comprising: one or more second processors; and second memorystoring second instructions that, when executed by the one or moresecond processors, cause the decision tree engine to: receive, from thedata integration engine, the user data; determine, based on the userdata, a financial action for the user, wherein determining the financialaction comprises determining results for each branch of a decision treethat associates the financial action with combinations of values of theestimated monthly expenses, the estimated monthly income, the estimatedemergency fund level, and the estimated high interest debt level; andcause, via a guidance user interface, an output of the financial action.2. The system of claim 1, wherein: the estimated monthly expenses areassociated with total monthly fixed expenses incurred by the user tocover essential needs; the estimated monthly income comprises a gross, anet, and a discretionary income; the estimated emergency fund level isbased on an amount of liquid assets available to cover the estimatedmonthly expenses; or the estimated high interest debt level isassociated with a loan with an interest rate above a pre-set threshold.3. The system of claim 1, wherein the first instructions, when executedby the one or more first processors, cause the data integration engineto determine the user data by causing the data integration engine to:receive, via the guidance user interface, first input data associatedwith the user, wherein the first input data associated with the usercomprises data corresponding to at least one of the user's monthlyexpenses, monthly income, emergency fund level, or high interest debtlevel; receive, from one or more external data servers, second inputdata associated with the user, wherein the second input data associatedwith the user comprises data corresponding to at least one of the user'smonthly expenses, monthly income, emergency fund level, or high interestdebt level; and generate, based on the first input data and the secondinput data, the user data.
 4. The system of claim 3, wherein at least aportion of the second input data is in a non-compliant format, andwherein the first instructions, when executed by the one or more firstprocessors, cause the data integration engine to generate the user databy further causing the data integration engine to: convert thenon-compliant format of the portion of the second input data into acompliant format; and validate the converted portion of the second inputdata by generating a plurality of test cases to test compliance of theconverted portion of the second input data and applying the plurality oftest cases to the converted portion.
 5. The system of claim 4, whereinthe first instructions cause the data integration engine to generate theplurality of test cases by causing the data integration engine togenerate test data configured to test a range of edge result casesassociated with the converted portion of the second input data.
 6. Thesystem of claim 3, wherein the first instructions, when executed by theone or more first processors, further cause the data integration engineto: based on the first input data and the second input data, generatesecond user data comprising: a variability score for each of theestimated monthly expenses of the user, the estimated monthly income ofthe user, the estimated emergency fund level of the user, and theestimated high interest debt level of the user, wherein the variabilityscore is based on a ratio of an interquartile range (IQR) or standarddeviation to a value, and wherein the value is the estimated monthlyexpenses, the estimated monthly income, the emergency fund level or thehigh interest debt level; and a reasonableness score for each of theestimated monthly expenses of the user, the estimated monthly income ofthe user, the estimated emergency fund level of the user, and theestimated high interest debt level of the user.
 7. The system of claim6, wherein the second instructions, when executed by the one or moresecond processors, cause the decision tree engine to determine thefinancial action for the user by causing the decision tree engine to:receive second user data; and determine the financial action for theuser further based on the second user data.
 8. The system of claim 1,wherein the first instructions, when executed by the one or more firstprocessors, further cause the data integration engine to determine theuser data based on one or more of the following: user augmented data;merchant category code; credit bureau data; geographic benchmarkestimates; a cost of living estimate; or a housing cost estimate.
 9. Thesystem of claim 1, wherein the user data comprises one or more of thefollowing: an emergency fund savings goal based on a monetary value ofone, three, or six months of committed monthly expenses; an emergencyfund shortfall based on an amount the user needs to save to reach theemergency fund savings goal; an emergency fund save rate based on as apercentage of a discretionary income the user allocates to the estimatedemergency fund level of the user; or an emergency fund timescale basedon a number of months to achieve the emergency fund savings goal. 10.The system of claim 1, wherein the first instructions, when executed bythe one or more second processors, cause the decision tree engine todetermine the financial action for the user by causing the decision treeengine to: generate a twelve-cell matrix based on: an estimated highinterest debt load of (1) none, (2) moderate, and (3) high, and anestimated emergency fund level of (1) less than one month of theestimated monthly expenses, (2) less than three months of the estimatedmonthly expenses, (3) less than six months of the estimated monthlyexpenses, and (4) greater than six months of the estimated monthlyexpenses.
 11. A method comprising: determining, by a data integrationengine, user data associated with an estimated monthly expenses of auser, an estimated monthly income of the user, an estimated emergencyfund level of the user, and an estimated high interest debt level of theuser; receiving, by a decision tree engine and from the data integrationengine, the user data; determining, by the decision tree engine andbased on the user data, a financial action for the user, whereindetermining the financial action comprises determining results for eachbranch of a decision tree that associates the financial action withcombinations of values of the estimated monthly expenses, the estimatedmonthly income, the estimated emergency fund level, and the estimatedhigh interest debt level; and causing, by the decision tree engine andvia a guidance user interface, an output of the financial action. 12.The method of claim 11, wherein the user data comprises one or more ofthe following: an emergency fund savings goal based on a monetary valueof one, three, or six months of committed monthly expenses; an emergencyfund shortfall based on an amount the user needs to save to reach theemergency fund savings goal; an emergency fund save rate based on as apercentage of a discretionary income the user allocates to the estimatedemergency fund level of the user; or an emergency fund timescale basedon a number of months to achieve the emergency fund savings goal. 13.The method of claim 11, wherein determining the user data comprises:receiving, via the guidance user interface, first input data associatedwith a user, wherein the first input data associated with the usercomprises data corresponding to at least one of the user's monthlyexpenses, monthly income, emergency fund level, or high interest debtlevel; receiving, from one or more external data servers, second inputdata associated with the user, wherein the second input data associatedwith the user comprises data corresponding to at least one of the user'smonthly expenses, monthly income, emergency fund level, or high interestdebt level; and generating, based on the first input data and the secondinput data, the user data.
 14. The method of claim 13, whereindetermining the financial action further comprises: based on the firstinput data and the second input data, generating, by the dataintegration engine, second user data comprising: a variability score foreach of the estimated monthly expenses of the user, the estimatedmonthly income of the user, the estimated emergency fund level of theuser, and the estimated high interest debt level of the user, whereinthe variability score is based on a ratio of an interquartile range(IQR) or standard deviation to a value, and wherein the value is theestimated monthly expenses, the estimated monthly income, the emergencyfund level or the high interest debt level; and a reasonableness scorefor each of the estimated monthly expenses of the user, the estimatedmonthly income of the user, the estimated emergency fund level of theuser, and the estimated high interest debt level of the user. receiving,by the decision tree engine and from the data integration engine, thesecond user data; and determining, by the decision tree engine, thefinancial action for the user further based on the second user data. 15.The method of claim 11, determining the financial action for the usercomprises: generating a twelve-cell matrix based on: an estimated highinterest debt load of (1) none, (2) moderate, and (3) high, and anestimated emergency fund level of (1) less than one month of theestimated monthly expenses, (2) less than three months of the estimatedmonthly expenses, (3) less than six months of the estimated monthlyexpenses, and (4) greater than six months of the estimated monthlyexpenses.
 16. A non-transitory computer-readable medium comprisinginstructions that, when executed by one or more processors, cause acomputing device to perform steps comprising: determining, by a dataintegration engine, user data associated with an estimated monthlyexpenses of a user, an estimated monthly income of the user, anestimated emergency fund level of the user, and an estimated highinterest debt level of the user; receiving, by a decision tree engineand from the data integration engine, the user data; determining, by thedecision tree engine and based on the user data, a financial action forthe user, wherein determining the financial action comprises determiningresults for each branch of a decision tree that associates the financialaction with combinations of values of the estimated monthly expenses,the estimated monthly income, the estimated emergency fund level, andthe estimated high interest debt level; and causing, by the decisiontree engine and via a guidance user interface, an output of thefinancial action.
 17. The non-transitory computer-readable medium ofclaim 16, wherein the user data comprises one or more of the following:an emergency fund savings goal based on a monetary value of one, three,or six months of committed monthly expenses; an emergency fund shortfallbased on an amount the user needs to save to reach the emergency fundsavings goal; an emergency fund save rate based on as a percentage of adiscretionary income the user allocates to the estimated emergency fundlevel of the user; or an emergency fund timescale based on a number ofmonths to achieve the emergency fund savings goal.
 18. Thenon-transitory computer-readable medium of claim 16, wherein theinstructions cause the computing device to determine the user data by:receiving, via the guidance user interface, first input data associatedwith a user, wherein the first input data associated with the usercomprises data corresponding to at least one of the user's monthlyexpenses, monthly income, emergency fund level, or high interest debtlevel; receiving, from one or more external data servers, second inputdata associated with the user, wherein the second input data associatedwith the user comprises data corresponding to at least one of the user'smonthly expenses, monthly income, emergency fund level, or high interestdebt level; and generating, based on the first input data and the secondinput data, the user data.
 19. The non-transitory computer-readablemedium of claim 18, wherein the instructions further cause the computingdevice to determine the financial action by: based on the first inputdata and the second input data, generating, by the data integrationengine, second user data comprising: a variability score for each of theestimated monthly expenses of the user, the estimated monthly income ofthe user, the estimated emergency fund level of the user, and theestimated high interest debt level of the user, wherein the variabilityscore is based on a ratio of an interquartile range (IQR) or standarddeviation to a value, and wherein the value is the estimated monthlyexpenses, the estimated monthly income, the emergency fund level or thehigh interest debt level; and a reasonableness score for each of theestimated monthly expenses of the user, the estimated monthly income ofthe user, the estimated emergency fund level of the user, and theestimated high interest debt level of the user, receiving, by thedecision tree engine and from the data integration engine, the seconduser data; and determining, by the decision tree engine, the financialaction for the user further based on the second user data.
 20. Thenon-transitory computer-readable medium of claim 16, wherein theinstructions cause the computing device to determine the financialaction by: generating a twelve-cell matrix based on: an estimated highinterest debt load of (1) none, (2) moderate, and (3) high, and anestimated emergency fund level of (1) less than one month of theestimated monthly expenses, (2) less than three months of the estimatedmonthly expenses, (3) less than six months of the estimated monthlyexpenses, and (4) greater than six months of the estimated monthlyexpenses.